4. Conclusions

15 4. The object-oriented and database fields can try to merge their capabilities to arrive at systems which can smoothly integrate the facilities for both, without prohibiting either a purely database-oriented approach or a purely object-oriented approach to the problem. We obviously prefer the fourth solution, and we believe that it is a promising direction to pursue. This presupposes, however, an open approach, accepting ideas from a different area, and respecting the limitations and constraints that each area poses. The limitations and constraints of object-oriented systems and database systems did not arise through chance or oversight. They arose because other principles and other ideas were heavily emphasized. Finally, we should note that a discussion on whether databases should be extended, or another field should redevelop its capabilities is not new to databases. For instance, the same difficulties arose with knowledge bases. Should knowledge bases be implemented on top of data-bases? Should databases be extended to incorporate knowledge base ideas? Or should knowledge bases provide their own storage and retrieval facilities? This controversy has not been settled completely and we are now embarking on similar discussions concerning object-oriented systems. In the end, it is not important whether object-oriented or database ideas prevail. Rather, it is important what facilities the final system offers. port for nearly all objects, namely for persistence and for maintaining object identifiers. Other issues, dealing with querying, indexing, efficient storage and transaction management, may be relevant only for a large number of well-structured objects belonging to few object classes. Highly active objects can be handled in more efficient ways than by keeping track of all their changes in a database. What we propose as a solution is to factor out the common database and object management support into a shared subsystem that is not seen by objects. Highly active objects can be stored and managed using the low-level object management subsystem. More passive objects with visible attributes exploit the same object management subsystem, but are provided with additional support for querying, etc. Given support for schema evolution, it is even possible for objects to migrate between the two parts of the object environment, either becoming more like database objects, or becoming more active. For example, redefining an object class to provide visible attributes for its instances will cause those objects to migrate to the database part of the object environment. This approach would also accommodate existing databases or …